\documentclass[a4paper, 12pt]{article}
\usepackage[T2A]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage[russian,english]{babel}
\usepackage[pdftex,unicode]{hyperref}
\usepackage[pdftex]{graphicx}

\begin{document}
KOT!. Спецификация.

Я никогда не писал-читал спецификации, поэтому не знаю как их писать, но есть множество поступков, которые я не делал ранее, а в первый раз они неплохо получились, например, дышать. Пусть каждый напишет, что он хочит видеть в самой лучшей IDE в мире и то, как это, примерно, реализовать.

Итак, моя мечта написать самую крутую IDE в мире для C\#/Java, а цель это получить славу и деньги, и кофеварку, хотя лучше боченок пива, с ethrnet-интерфейсом. Так как все успешные продукты - клоны более совершенных, то конкуренты меня не пугают. В качестве основы для нашего успешного проекта возмем наиболее совершенные IDE - Smalltalk-like и IDEA (мы новые JetBrains, наверное, getMozg), а так же добавим свои фишки и поработим мир.

Что я имею ввиду под Smalltalk-like IDE? В основном это представление кода. Если мы оперируем такими сущностями как классы, методы, свойства, то почему бы в работе не редактировать бы эти сущности, а не файлы. Идея проста и именно она реализована в Smalltalk-like IDE. Ниже приведено ужасное подобие того, как это будет выглядеть.
\includegraphics*{smalltalk-like-ide.png}

То есть формально написана только одна строчка кода - все остально сделано (в идеале) горячими клавишами и через визарды. В классичиских IDE пришлось бы писать следующий код:\\
1 using System;\\
2 namespace HelloWorld\{\\
3 \quad public class Program\{\\
4\quad\quad public static void Main(string[] args)\{\\
5\quad\quad\quad Console.WriteLine("Hello, world");\\
6\quad\quad\}\\
7\quad\}\\
8 \}

Кроме эстетическо-гуманитарно-ленивых чувств от такой организации работы, есть еще множестно техноческо-прагматичных плюсов:

\begin{itemize}
\item Рефакториг. Так так нужно парсить только тело метода, то даже такие вафлы, как мы, могут без больших проблем его добавить.
\item Проект. Можно забить на подход классических IDE к понятию проект и ввести правило: "один проект - один файл".
\item Система контроля версий. Возможность с.к.в. выдавать сообщения не вида "файл x устарел", а "в класс у добавлен метод z".
\end{itemize}

К сожалению мы не можем позволить себе создавать еще и систему контроля версий, как полноценный продукт, но можно создать недопродукт и интегрировать его в KOT!. Так как проект это файл, то можно научить IDE сравновать эти файлы и выдовать различия в стиле идеальной с.к.в. ("в класс у добавлен метод z")

Другая проблема состоит в том, что не имея своей системы контроля версий, сложно использовать уже существующие, так как они ориентированы на проекты-помойки, а не на проекты-файлы. А отказываться от проекта-файла или от поддержки с.к.в. глупо, поэтому придется ввести опцию сохранять проект и как проект-помойку, но в особом формате. Пусть папки это пространства имен и классы, а файлы - это методы. Один метод - один файл. Пусть формат метода-файла будет примитивен (с точки зрения .NET) - сериализованный объект класса метод из DOM. Тогда проект-файл можно ввести просто как заархивированный проект-помойка.

Наверное, создание KOT! большое дело, поэтому оно хорошо распадается на подзадачи:

\begin{enumerate}
\item DOM (объектная модель документа - кода)
\begin{enumerate}
\item НедоDOM будет использоваться на начальном этапе, когда важно создать хоть что-то, что работает, а так же тесты, создав недоDOM можно будет сделать GUI, проект-файл, конверторы проект-файл$\leftrightarrow$проект-помойка. Итак недоDOM - это классы для представления:
\begin{itemize}
\item Классов
\item Пространств имен
\item Методов
\item Свойств
\item Полей
\item Аттрибутов
\end{itemize}
\end{enumerate}
\begin{enumerate}
\item DOM - это полноценный DOM для представления языка C\#. Реализовав его можно будет доделать проект-файл и начать писать парсер тела методов. Итак, DOM - это недоDOM + классы для представления чего-нибудь вроде следующего:
\begin{itemize}
\item цикл foreach
\item объявления переменных
\item \dots
\end{itemize}
\end{enumerate}
\item Структура проекта-файла (зависит от недоDOM, после от DOM)
\item Консольные утилиты для работы с проектом:
\begin{enumerate}
\item Поиск различий в проектах-файлах
\item Конвертор проект-файл$\leftrightarrow$проект-помойка
\item Конвертор проект-файл$\to$nant-скрипты
\item Конвертор проект-файл$\to$msbuilt
\end{enumerate}
\item Парсер тела методов, по сути конвертор тело метода$\to$ представление DOM. Означает, может быть начат после создания всего DOM
\item GUI - Интерфейс пользователя. Думаю, что должен быть максимально функциональным, но и удобным, и user-friendly. Это не пародокс. Вероято, должно быть окно справки, в которой описывается текущее состояние IDE и присок горячих клавиш, которые могут быть применены в данный момент. GUI должен быть таким, что допускает работу без участия мыши.
\begin{enumerate}
\item Черновик, которые работает с недоDOM (зависит от недоDOM)
\item Поддержка примитивного автодополнения (зависит от недоDOM)
\item Работа с текстом - поиск, замена$\dots$
\item Подцветка синтаксиса (зависит от DOM)
\end{enumerate}
\item Рефакторинг (зависит от DOM)
\begin{itemize}
\item встроенный в GUI (зависит от GUI)
\item отдельное консольное приложение (зависит от файла-проекта)
\end{itemize}
\end{enumerate}

После того, как все это будет сделано - это будет только половина. Останется создать уйму плагинов для таких вещей, которые есть в студии, как app.config, settings1.settings, и так далее и тому-подобное$\dots$

\LARGE Мы захватим мир
\end{document}
